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SECTION  1 
INTRODUCTION 


1.1  BACKGROUND 

This  report  covers  Task  F,  "How  Current  and  Developing  Systems  and 
Their  Associated  Management  Procedures  Should  Support  the  Requirements  of 
an  On-Line  SACS,"  of  an  ODCSOPS  project  entitled  "Analysis  to  Determine 
Functional  and  Systems  Requirements  for  an  On-Line  Structure  and  Compo- 
sition System  (SACS),"  Contract  Number  MDA903-78-C-0445,  dated  26  Septem- 
ber 1978.  Task  F requires  that  a conceptual  framework  for  on-line  SACS 
operations  be  developed.  The  task  objectives  were  to: 

• Define  the  system  concept  for  an  improved  on-line  SACS. 

• Specify  modifications  required  in  current  and  developing 
systems  and  their  data  elements  to  support  the  concept. 

• Identify  other  requirements  related  to  the  defined  SACS 
concept. 

1.2  RESEARCH  METHODOLOGY 

The  methodology  employed  was  to  relate  the  proposed  SACS  concept 
to  the  current  and  developing  systems  that  either  provide  data  to  SACS 
or  are  planned  to  provide  data  to  SACS  in  the  future  to  determine: 

• How  these  systems  should  support  an  improved  on-line  SACS. 

• How  their  associated  management  procedures  should  support 
the  improved  on-line  SACS. 

The  approach  involved  continued  review  of  existing  systems  and  user 
documentation,  and  discussions  with  system  proponents  and  development 
personnel . 


1.3  SCOPE 

The  scope  of  this  task  involved  synthesis  of  previously  proposed^ 
changes  to  force  structure  and  related  systems  into  a viable  concept  that 
would  be  feasible  for  supporting  the  improved  on-line  SACS.  Systems  in- 
volved were  the  Force  Development  Integrated  Management  System  ( FORD IMS ) , 
the  Vertical  Force  Development  Management  Information  System  (VFDMIS) , 
the  Table  of  Organization  (TOE)  file,  the  Basis  of  Issue  Plan  (BOIP)  file, 
and  the  Short  Hand  Motes  (SHN)  file.  Also  considered  was  the  Phased 
Equipment  Modernization  (PEM)  program  being  developed  at  the  US  Army 
Depot  Systems  Command  (DESCOM)  for  the  purpose  of  obtaining  an  Equipment 
Phasing  File  (EQPF) . 


1.4  REPORT  ORGANIZATION 

Section  2 defines  the  operational  concept  of  the  improved  on-line 
SACS.  Section  3 defines  changes,  enhancements,  and  additions  to  current 
and  developing  systems  necessary  to  implement  the  concept. 


F.  0.  Deppner  et  al.,  Report  of  Task  D - Data  Requirements  Document, 
General  Research  Corporation,  1070-03-79-CR,  May  1979;  F.  0.  Deppner 
et  al..  Report  of  Task  E - Analysis  of  Current  and  Developing  Systems 
Which  Interface  with  LOGSACS  and  PERSACS  to  Determine  to  What  Extent 
They  Do  or  Do  Not  Support  the  Data  Requirements  of  an  On-Line  SACS. 
General  Research  Corporation,  10 70-04- 79-CR,  June  1979. 


SECTION  2 

OPERATIONAL  CONCEPT  FOR  THE  IMPROVED  ON-LINE  SACS 

2.1  CONCEPT 

The  improved  on-line  SACS  concepc  is  based  on  the  premise  that 
feeder  data  will  be  accurate  and  timely  in  each  respective  feeder  system; 
therefore,  SACS  data  provided  through  the  LOGSACS  and  PERSACS  files  to 
the  ARSTAF  and  field  activities  will  be  accurate  and  timely.  The  concept 
assumes  maximum  use  of  interactive  conversational  software.  Figure  2.1 
is  a general  conceptual  data-flow  schematic  which  depicts  the  overview 
of  the  improved  on-line  SACS  concept  for  both  ODCSOPS  and  ODCSPER. 

This  concept  requires  terminals  be  Installed  in  the  ODCSOPS  (SACS 
Branch)  and  in  ODCSPER  (as  designated)  to  initiate  the  various  processes 
necessary  to  develop  the  LOGSACS  and  PERSACS.  All  data  inputs  will  be 
stored  on  line  for  immediate  access,  and  all  outputs  will  be  stored  on 
line  for  retrieval  as  required.  The  exceptions  are  the  magnetic  tape 
files  that  must  be  transported  to  different  computer  sites  for  processing 

The  concepc  will  utilize  data  developed  by  other  systems  except 
that  the  SHN  for  LOGSACS  must  be  developed  by  ODCSOPS  (DAMO-FDA)  and  for 
PERSACS  must  be  developed  by  ODCSPER  (responsible  organization  entity  to 
be  designated).  The  SHN  file  will  be  developed  on  line  and  include  the 
capability  to  establish  recurring  or  one-time  use  data.  The  SHN  capa- 
bility will  be  to  add  or  adjust  data  prior  to  producing  final  outputs. 

The  SACS  module  will  be  composed  of  all  required  SACS  functions  to 
include  ODCSOPS  processing  of  BOIP  and  SHN  to  equipment  data  for  LOGSACS 
purposes.  In  PERSACS,  however,  the  ODCSOPS  processes  stop  after  the 
basic  PERSACS  file  is  developed  and  personnel  factoring  takes  place. 
Therefore,  it  is  assumed  that  ODCSPER  will  be  responsible  for  the  pro- 
cessing of  BOIP,  Personnel  Short  Hand  Notes  (PSHN) , EQPF,  and  projected 
personnel  assets  to  the  basic  PERSACS  file.*  Appendix  A lists  other 

* Assumption  Number  9,  Appendix  A. 


assumptions  that,  if  approved,  will  establish  some  of  the  basic  guidance 
for  developmental  and  operational  aspects  of  the  improved  on-line  SACS. 

The  processing  of  SACS  will  be  a continuous  day-to-day  effort  so 
that  the  scheduled  production  of  LOGSACS  and  PERSACS  can  take  place  with 
minimal  notice  and  within  hours  instead  of  weeks  as  is  current  practice. 
The  LOGSACS  and  PERSACS  data  as  produced  for  use  by  various  functions 
and  systems  will  be  maintained  for  historical  purposes  on  magnetic  tape 
and  on  line  as  the  Army's  requirements  and  authorizations  data  base  for 
retrieval  and  ad  hoc  report  purposes.  This  data  base  will  be  replaced 
with  the  same  frequency  as  the  LOGSACS  and  PERSACS  production  schedule. 

The  SACS  data  base  update  process  will  be  to  retrieve  records  from 
the  feeder  data  bases  and  replace  data  in  SACS.  The  SACS  software  will 
perform  minimal  editing  since  it  is  assumed  that  all  feeder  data  are 
correct.  In  interfacing  the  feeder  system  data,  erroneous  control  infor- 
mation such  as  UIC,  SRC,  and  CCNUM  will  be  reported  to  appropriate  feeder 
system  personnel  for  correction.  A change  file  for  suspense  control  will 
be  maintained  to  ensure  that  corrections  are  made  to  feeder  system  data. 

The  overall  SACS  concept  will  not  require  USAMSSA  analyst  or  pro- 
grammer intervention  once  completely  implemented.  The  mounting  of  mag- 
netic tapes  on  tape  drives  to  load  on-line  files  will  be  the  only  USAMSSA 
involvement  in  the  generation  of  the  LOGSACS  and  PERSACS.  All  other  SACS 
functions  will  be  initiated  and  controlled  by  terminal  operators  located 
in  ODCSOPS  (DAMO-FDA) . 

Appendix  B lists  timeliness  requirements  for  SACS  data.  The  time- 
liness requirements  as  stated  represent  the  time  interval  for  data  to 
flow  between  systems  and  to  be  processed  within  a system  as  well  as  the 
time  interval  required  for  SACS  data  users  to  respond  to  functional 
requirements  as  a result  of  data  changes.  These  time  intervals  are 

^■Requisition  lead-time,  training  lead-time,  procurement  lead-time. 


identified  in  Appendix  B as  "system  time"  and  "functional  time."  As 
policy  or  other  changes  cause  either  of  these  time  intervals  to  change, 
the  projected  time  will  increase  or  decrease  accordingly. 

The  improved  on-line  SACS  processes  encompass  current,  developing 
and  to  be  developed  files.  The  premise  in  using  these  files,  in  the 
future  SACS,  is  that  they  will  be  completely  maintained  within  their 
respective  system  operational  environments  and  no  udpate  or  change  to 
their  data  will  be  required  in  the  SACS  operational  environment.^-  There- 
fore, each  SACS  feeder  file  will  be  provided  by  a single  authoritative 
data  source.  All  other  Army  users  of  these  files  will  be  using  iden- 
tical data  and  improved  data  standardization  will  result  from  implement- 
ing this  concept. 

The  future  SACS  operational  concept  is  based  on  the  premise  that 
terminal  operations  personnel  in  ODCSOPS  (DAMO-FDA)  will  initiate  freez- 
ing the  force,  loading  files,  and  controlling  all  processes,  thus  obviat- 
ing the  need  for  submitting  a Data  Processing  Request  (DPR)  to  USAMSSA 
prior  to  each  SACS  run.  Therefore,  when  ODCSOPS  defines  the  SACS  force 
selection  criteria,  it  will  be  input  via  terminal.  Simultaneously,  via 
terminal,  the  required  files  will  be  identified  by  title,  label,  and 
volume  serial  number  so  that  only  USAMSSA  operational  personnel  and  com- 
puter resources  are  utilized  and  not  USAMSSA  systems  analysts  and  pro- 
grammers. This  concept  will  be  employed  throughout  the  entire  future 
2 

SACS  processes.  The  future  SACS  will  be  capable  of  functioning  on  a 
continuing  basis  throughout  each  day  to  process  some  aspect  of  SACS  and 
to  prepare  for  the  actual  scheduled  production  of  the  LOGSACS  and  PERSACS. 
The  daily  SACS-type  processing  may  Include  BOIP  impact  processing,  SHN 
development  and  processing,  and  force  review  with  respect  to  specific  type 
units  or  specific  UIC.  The  results  of  daily  processes  would  be  stored 

^Some  processing  details  must  change;  proposed  required  changes  are 

discussed  in  Section  3 of  this  report. 

2 

SIGMA-,  basic  SACS-,  LOGSACS-,  and  PERSACS-type  processes. 
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for  use  in  producing  SACS  products,  thereby  greatly  reducing  the  amount 
of  time  required  to  develop  the  LOGSACS  and  PERSACS,  since  their  develop- 
ment would  be  a continuous  ongoing  process  transparent  to  SACS  product 
recipients. 

An  integral  part  of  the  future  SACS  will  be  an  audit  capability  to 
account  for  all  units  by  UIC  that  are  registered  in  the  force,  all  unit 
header  records  and  all  personnel  and/or  logistic  detail  records.  This 
concept  will  introduce  a control  capability  which  has  not  been  previously 
available  to  ensure  that  all  units  and  their  detail  data  are  produced  in 
each  LOGSACS  and  PERSACS. 

To  reduce  computer  processing  time,  a procedure  to  identify  the 
processing  date  (YYMMDD)  must  be  established  so  that  records  that  have 
not  undergone  change  since  the  last  processing  are  not  processed  again. 

By  precluding  the  need  for  processing  records  that  have  not  changed, 

SACS  analysts  will  have  more  time  to  analyze  changes  instead  of  review- 
ing all  records  in  given  categories.  However,  all  records  will  always 
be  included  in  the  LOGSACS  and  PERSACS  products. 

2.2  DATA  SOURCES 

The  improved  on-line  SACS  data  sources  will  be  identical  to  current 
sources  except  as  they  are  modified  or  changed  in  the  future  by  develop- 
ing systems.  The  sources  for  data  will  be  as  follows: 

• ODCSOPS/ODCSPER  will  provide  the  force  structure  and  manpower 
management  data  through  two  principal  subsystems  of  FORDIMS. 

They  are  the  Force  Structure  Subsystem  (FSS)1  and  the  Authori- 

2 

zations  Subsystem  (AS) . FORDIMS  will  be  replaced  by  VFDMIS 
in  approximately  L to  3 years. 

• TRADOC  will  provide  the  TOE  and  BOIP  files.  TRADOC  will  be 
required  to  provide  these  files  for  the  future  SACS  processes 


^Replaces  the  Force  Accounting  System  (FAS) . 
^Replaces  the  HQDA  TAADS. 


based  on  HQDA  needs  so  that  current  USAMSSA  processes  will 
not  be  required. 

e ODCSOPS/ODCSPER,  in  conjunction  with  other  interested  ARSTAF 
and  field  activities,  will  develop  the  SHN  for  application  to 
the  equipment  and  personnel  data  produced  in  the  LOGSACS  and 
PERSACS  respectively.  The  personnel  SHN  concept  must  be  com- 
pletely developed  since  it  presently  does  not  exist. 

e ODCSLOG/DESCOM  will  provide  an  EQPF  which  will  be  the  basis 
for  coordinating  equipment  and  personnel  phasing.  This  file 
and  its  use  must  be  developed  since  they  presently  do  not 
exis  t . 

2.3  DATA  TIMELINESS  AND  ACCURACY 

The  data  timeliness  of  the  future  SACS  is  related  to  the  introduc- 
tion of  simple,  yet  adequate  EDATE  rules,  coupled  with  requirements  for 
projecting  data  a sufficient  amount  of  time  into  the  future  to  ensure 
that  the  logistics  and  personnel  functional  managers  have  sufficient 
"functional"  time  to  react  to  changes  in  resource  requirements.  For 
example,  personnel  managers  must  have  time  to  respond  to  normal  requi- 
sitioning, training,  and  other  demands  and  the  logistics  managers  must 
have  time  to  respond  to  normal  requisitioning,  procurement  lead-time, 
and  order-ship- time  requirements.  Appendix  B identifies  the  time  require- 
ments and  relates  them  to  resource  changes.  A resource  change1  for  per- 
sonnel is  construed  to  be  any  change  in  authorized  grade  and/or  military 
occupational  specialty  (MOS)  of  a position  even  though  the  aggregate 
number  of  military  personnel  positions  may  not  change.  A resource  change 
for  equipment  is  the  change  or  addition  of  a line  item  number  (LIN)  or  an 
increase  in  an  existing  LIN  quantity.  Since  the  various  MOS  and  LIN  have 
different  lead  times,  based  on  length  of  training  courses  and  length  of 
production  cycles  respectively,  the  DCSPER  and  DCSLOG  will  need  to 

1Dlrected  changes  based  on  the  semi-annual  MOS  change  guidance  and 
SB700-20  guidance  are  not  considered  in  this  category.  Changes  directed 
from  MACOM  or  other  headquarters  are  in  this  category. 


periodically  publish  lead-time  criteria  for  all  MOS  and  LIN  for  use  by 
TAADS  documentation  personnel  in  all  MACOMs . 

The  future  SACS  required  data  accuracy  is  a 100%  standard,  in  that 
SACS  products  must  reflect  data  that  are  equal  to  those  which  are  resident 
in  field  user  files.  The  requirements  and  authorizations  data  used  at 
the  installation  level  as  the  basis  for  generating  personnel  and  equip- 
ment requisitions  must  be  identical  to  the  SACS  requirements  and  authori- 
zations data  provided  to  ODCSPER,  0DCSL0G,  and  ODCSRDA  functions.  There- 
fore, functional  users  will  have  the  capability  tc  validate  requirements 
utilizing  data  identical  to  those  that  were  the  basis  for  generating  the 
requirement. 


2.4  IMPROVED  ON-LINE  SACS  LOGIC  CONCEPT 

The  improved  on-line  SACS  is  based  on  the  premise  that  control  must 
be  vested  in  the  functional  analysts  who  are  responsible  for  preparing 
the  LOGSACS  and  PERSACS.  Therefore,  the  future  SACS  logic  requires  that 
all.  automated  processes  be  programmed  and  properly  catalogued  for  initia- 
tion via  terminal.  This  concept  will  require  that  SACS  analysts  in 
ODCSOPS  (DAMO-FDA)  be  the  focal  point  for  coordinating  actions  that  have 
impacts  on  SACS  input  files  and  output  products.  The  ODCSOPS  SACS  Branch 
is  the  focal  point  responsible  for  SACS  data  and,  therefore,  the  person- 
nel of  this  branch  are  key  coordinators  and  problem  solvers  of  perceived 
or  real  problems  contained  in  SACS  products.  An  operational  aspect  of 
future  operations  of  SACS  must  be  the  recognition  of  this  responsibility 
and  appropriate  ARSTAF  and  field  directives  must  be  promulgated  concerning 
SACS  objectives,  uses,  schedules,  responsibilities,  and  products.  These 
directives  must  be  augmented  by  published  SACS  functional  user  guides. 


The  internal  ODCSOPS  (DAMO-FDA)  future  SACS  operations  will  require 
close  supervision  over  data  flow,  specific  file  Identification,  and  volume 
serial  numbers  of  mailed  files.  This  will  be  particularly  important  for 


^Volume  serial  number  identifies  the  catalogued  serial  number  of  a reel 
of  magnetic  tape. 


control  over  Input  data  to  ensure  that  the  latest  files  are  being  used 
and  to  ensure  that  important  events  are  recorded  in  the  respective  files. 
Through  tracking  functional  force  structure  actions  and  managing  the  data 
inputs  to  SACS,  the  SACS  analysts  will  be  better  equipped  to  respond  to 
changes  and  questions.  The  SACS  operational  logic  will  require  that  SACS 
terminal  operators  key-in  appropriate  file  identification  for  the  various 
SACS  processes.  Such  information  may  require  that  USAMSSA  load  files 
prior  to  SACS  processing  where  the  specific  file  is  not  resident  on  disk. 
The  SACS  software  will  prompt  the  terminal  operator  through  the  various 


SACS  processing  options  so  that  minimal  USAMSSA  computer  operator  inter- 
vention is  required.  The  typical  options  that  will  be  built  into  the 
future  SACS  for  terminal  operator  use  are: 

e Sign-On  SACS  - specify  option  desired 

e Freeze  Force  - specify  parameters 

• Load  Files  - specify  file  and  volume  serial  number 
e Develop  Short  Hand  Notes  - specify  function 


Analyze  Resource  Impacts  - specify  parameters 
Process  - specify  processes 
Generate  Recurring  Reports  - specify 

Generate  Ad  Hoc  Reports  - specify  data,  sequence,  format 

Review  Audit  - specify  files 

Copy-Back-Up  - specify  files 

Load-Back-UP  - specify 

Analyze  PERSACS  - specify 

Analyze  LOGSACS  - specify 


The  option  list  of  major  functions  will  be  further  subdivided  into  sub' 
options  which  the  terminal  operator  will  specify  or  default  will  apply 
which  may  automatically  initiate  processing.  The  option  "process"  may 
Include  suboptions  as  follows: 


Compare  FSS  and  AS  and  identify  errors 
Develop  error  transactions  for  processing 
Develop  error  transactions  for  review  and  processing 
Develop  error  transaction  suspense  control 
Identify  and  select  required  SRC  from  TOE 


• Perform  SRC  assembly  - display  results 

• Perform  negative  suppression  - display  results 

• Apply  B01P  data  to  LIN  - apply  SHN  data  to  LIN 

• Apply  phasing  data 

• Split  units  identification 

• POMCUS  logic  exceptions 

• Audit  totals  review 

• Reimbursable  authorizations  identified 

This  is  a representative  list  of  potential  suboptions  for  processing  under 
the  major  option  "process"  and  it  is  not  intended  to  be  an  actual  option 
list. 


The  overall  improved  SACS  concept  will  be  capable  of  providing 
LOGSACS  and  PERSACS  files  to  the  functional  users  within  several  days 
instead  of  the  3 to  6 weeks  that  are  presently  required.  Also,  the  SACS 
production  schedule  could  be  changed  drastically  and  because  of  flexibil- 
ity of  the  future  SACS  the  impact  on  workload  would  be  minimal. 


SECTION  3 


REQUIRED  SYSTEM  AND  PROCEDURAL  CHANGES 
TO SUPPORT  THE  IMPROVED  ON-LINE  CONCEPT 


3.1  GENERAL 

The  future  SACS  objectives^  of  providing  data  that  are  100%  accurate 
and  timely  were  principal  considerations  in  developing  the  list  of  changes 
and  system  development  actions  that  are  described  below. 

3.2  DATA  MANAGEMENT 

An  ARSTAF  force  structure  System  Configuration  Management  and  Control 
Group  (SYCMACG)  should  be  established  under  a Chief  of  Staff  Memorandum 
(CSM)  as  soon  as  possible.  The  SYCMACG  would  consist  of  a chairperson 
and  recording  secretary,  provided  by  ODCSOPS(DAMO-FDA) , with  appropriate 
ARSTAF  and  field  activity  representatives.  The  principal  justifications 
for  establishing  this  group  are  that  force  structure  actions  which  estab- 
lish resource  requirements  and  authorizations  create  a "thread"  through 
force  structure  systems  to  the  logistic  and  personnel  functions  and  sys- 
tems. and  that  as  force  structure  systems  implement  changes,  so  should 
functional  systems  to  ensure  that  intended  benefits  are  actually  achieved 
by  all  users  of  requirements  and  authorizations  data. 

The  Initial  SYCMACG  responsibility  would  be  to  develop  and  coor- 
dinate its  operational  concept  to  include  scope,  objectives,  and  detailed 
responsibilities,  and  prepare,  coordinate,  and  publish  an  appropriate 
SACS  regulation  which  would  specifically  establish  its  current  and  future 
role  in  the  force  structure,  logistics,  and  personnel  functional  areas. 

In  order  to  be  effective,  the  SYCMACG  should  be  the  coordination 
point  for  all  SACS  related  data,  SACS  issues  and  problems,  and  changes 
to  SACS  feeder  systems.  Specifically,  the  SYCMACG  would  be  responsible 
for  processing,  reviewing,  and  recommending  changes  and  revisions  to: 

^F.  0.  Deppner  et  al..  Report  of  Task  C - Data  Analysis  of  Accuracy  and 
Timeliness.  General  Research  Corporation,  1070-02-79-CR,  March  1979. 


• SACS  system  configuration  baseline 

• Data  flow 

• Edit  rules 

• Audit  rules 

• Processing  criteria 

• Interface  requirements 

• Functional  system  requirements  of  SACS  and  feeder  systems. 

• Procedures  applicable  to  current,  budget,  and  POM  years 

• Documentation  requirements 

• Operational  concepts 

3.3  DEVELOPING  SYSTEMS 

The  FORDIMS  and  VFDMIS  are  identified  as  developing  systems  with 
FORDIMS  scheduled  for  complete  impelementation  by  end  calendar  year  1979 
and  VFDMIS  scheduled  for  implementation  in  the  third  quarter  calendar 
year  1980.  These  systems  will  provide  improved  accuracy  and  timeliness 
in  data  inputs  to  SACS  with  the  most  significant  improvements  being  built 
into  VFDMIS.  VFDMIS  will  accommodate  many  beneficial  improvements  in  the 
force  structure  systems.  As  a result  of  implementing  VFDMIS  planned 
improvements  (defined  in  Appendix  D)  and  those  improvements  identified 
below,  the  ARSTAF  will  be  provided  an  excellent  enhancement  to  the  current 
force  structure  systems. 

3.4  RECOMMENDED  CHANGES  TO  SUPPORT  THE  IMPROVED  ON-LINE  SACS 

The  rules  identified  below  should  be  viewed  as  standards  and  objec- 
tives that  should  be  implemented  as  soon  as  possible,  but  not  later  than 
the  date  of  the  implementation  of  VFDMIS. 

3.4.1  EDATE  Rules 


3. 4. 1.1  Applicability 

EDATE  rules  should  be  implemented  in  VFDMIS,  FORDIMS  (both  FSS  and 
AS),  TAADS,  and  ITAADS. 
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3. 4. 1.2  Proposed  Rules 

a.  EDATEs  will  be  assigned  to  a specific  date  each  month  to 
accommodate  readiness  reporting  as  well  as  all  other  functi.  ial  actions 
The  16th  of  each  month  will  best  accommodate  all  needs. 


b.  The  time  interval  between  EDATEs  of  any  one  UIC  must  be  at 
least  6 months. 


c.  Initial  EDATEs  will  be  established  following  the  timeliness 
criteria  related  to  data  elements  contained  in  Appendix  B as  follows: 


Short  Range 
(Months; 


Long-Range 
(Months ) 


LOG  CONUS 


PER  CONUS 


d.  Changes  to  established  EDATEs  must  reflect  the  above  criteria 


(1)  No  current  year  EDATE  change  will  be  permitted 


(2)  No  budget  year  EDATE  change  will  be  permitted  unless  the 
time  interval  between  the  current  date  and  the  EDATE  is  at  least  equal 
to  the  applicable  short-range  time  requirement  and  no  specific  LIN  or 
MOS  lead-time  criteria  arc  applicable.  If  specific  LIN  or  MOS  criteria 
apply,  no  change  in  EDATE  will  be  permitted  in  the  budget  year. 


(3)  No  program  year  EDATE  change  will  be  permitted  unless  the 
time  interval  between  the  current  date  and  the  EDATE  is  at  least  equal 
to  the  applicable  mid-  or  long-range  time  requirement. 


ODCSOPS,  ODCSLOG,  and  ODCSPER  will  be  required  to  publish,  , 
annually,  the  specific  lead-time  criteria  by  type  unit,  LIN 
for  use  in  the  mid-  and  long-range  time  frame. 


(4)  EDATE  changes  to  program  outyears  may  be  made  at  any  time 
providing  the  mid-  and  long-range  time  interval  criteria  are  met. 

e.  EDATE  rules  are  applicable  to  proponent  approved  and  pro- 
ponent proposed  requirements  and  authorization  documents. 

f.  EDATE  rules  are  applicable  to  LIN,  MOS,  grade,  and  quantity 
changes . 

g.  HQDA  may  approve  exceptions,  as  required. 

3.4.2  Requirements  and  Authorizations  Documentation  Rules 

3. 4. 2.1  Applicability 

Requirements  and  authorizations  documentation  rules  are  applicable 
to  VFDMIS,  FORDIMS  AS,  TAADS , and  1TAADS. 

3. 4. 2. 2 Proposed  Rules 

a.  Unit  documentation  once  submitted  to  HQDA  for  an  EDATE  cannot 
be  changed  until  the  next  applicable  EDATE. 


b.  Unit  documentation  once  submitted  to  HQDA  for  a CCNUM  cannot 
be  changed  unless  rule  a applies  and  a new  CCNUM  is  utilized. 

c.  Unit  documentation  will  not  be  changed  until  a time  interval 
of  at  least  6 months  has  elapsed  from  last  change  or  until  the  next  EDATE 
whichever  provides  the  shortest  time  interval. 

d.  HQDA  may  approve  exceptions,  as  required. 


3.4.3  Edits 


3. 4. 3. 2  Applicability 

Edit  rules  are  applicable  to  VFDMIS,  FORDIMS,  TAADS,  TOE,  BOIP,  SHN, 
EQPF,  and  other  systems  that  may,  in  the  future,  interface  with  SACS. 
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3.4. 3.2  Proposed  Rules 

a.  All  SACS  feeder  systems  must  perform  data  value  edits  at  time 
of  input  so  that  stored  data  values  are  100%  accurate  when  provided  to 
SACS.1 


b.  Data  values  must  be  formulated  by  responsible  functional  area 
personnel  in  accordance  with  approved  SYCMACG  guidance. 

c.  Changes  to  the  automated  edit  tables  or  files  must  be  verified 
and  updated  by  responsible  functional  area  personnel  at  least  once  each 

6 months. 

d.  All  input  data  elements  will  be  edited  against  appropriate 
authorized  data  element  values. 

e.  All  input  data  element  values  will,  be  edited  for  compatibility 
with  other  data  values  in  the  same  record  and  for  logic  with  data  element 
values  stored  in  other  records  describing  the  same  UIC. 
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f.  Edit  value,  edit  standards,  and  edit  logic  will  have  equal 
applicability  to  all  force  structure  systems  processing  source  data  input. 

g.  Each  interface  must  identify  which  system  will  provide  the 

2 

authoritative  data  in  the  case  of  mismatched  data  values. 


The  principal  systems  are  currently  FORDIMS  and  TAADS.  As  evolutionary 
changes  are  made  to  these  systems,  edit  improvements  should  be  imple- 
mented as  feasible. 

2 

Edit  rules  apply  to  data  interface  only  to  the  extent  that  when  data 
appear  to  be  in  error  one  system  must  be  accepted  as  correct  so  that 
processing  continues. 
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3.4.4  Audit 

3. 4. 4.1  Applicability 

Audit  rules  are  applicable  to  VFDMIS,  Unit  Identification  System 
(UIS),  FORD IMS,  TAADS,  and  SACS. 

3. 4. 4. 2 Proposed  Rules 

a.  All  UICs  registered  in  the  UIS  which  receive  an  allocation  of 
manpower  or  equipment  must  be  reflected  in  all  force  structure  systems.*- 


b.  All  UICs  (rule  a)  will  reside  on  a file  updated  daily  by  the 

2 

UIS  and  be  accessible  by  all  force  structure  systems.  Such  control  files 
must  reflect  all  applicable  UIC  EDATEs. 


c.  Once  a MACOM  UIC  Information  Officer  (UICIO)  registers  a UIC 
in  the  UIS  and  rule  a applies,  the  TAADS  submission  to  HQDA  must  be  within 
90  days. 


d.  Registered  UICs  will  be  the  basis  for  UICs  to  exist  in  all 
force  structure  systems  with  an  exception  being  made  for  planning  units 


e.  FORDIMS(FSS)  will  identify  which  units  must  have  both  personnel 
and  logistics  detail  data  records  or  which  type  detail  data  records,  if 
only  personnel  or  logistics  data  are  applicable. 


f.  All  systems  will  establish  controls  to  account  for  all  units 
and  their  respective  personnel  and/or  logistics  detail  records  to  ensure 
that  UICs  and  the.lr  applicable  detail  are  always  available  throughout  a 
unit's  life  cycle. 


ODCSPER  and  MILPERCEN  systems  should  use  identical  UIC  audit  and  control 
techniques  as  force  structure  systems.  Note  rule  b.  All  systems  should 
use  the  identical  control  file.  The  different  functional  areas  should 
not  utilize  unique  update  systems  fed  by  UIS  changes. 

The  UIS  is  operated  by  the  0DCS0PS  command  and  control  system.  A daily 
file  transported  to  USAMSSA  and  loaded  thereon  for  edit  and  control  will 
serve  this  purpose. 


g.  SACS  will  account  for  all  UICs  and  the  applicable  personnel 
and  logistics  detail  records  prior  to  each  production  run.  Exceptions 
will  be  identified  for  corrective  action  and  special  reporting.  Through 
each  SACS  process,  record  counts  will  be  utilized  to  ensure  that  output 
record  volume  equals  the  input  record  volume.  If  differences  between 
these  record  counts  occur,  they  will  be  investigated  and  corrected  or 
explained  to  recipients  of  LOGSACS  and  PERSACS. 

h.  SACS  will  have  an  audit  module  that  will  provide  record  count 
displays  and  hard  copy  reports  of  the  UIC  header  records  and  equipment 
and  personnel  detail  data  records  for  review  at  each  processing  step 
where  record  handling  takes  place. 

3.4.5  Data  Flow 


3. 4. 5.1  Applicability 

Data  flow  rules  must  be  implemented  in  VFDMIS,  FORD IMS,  and  TAADS. 
These  data  flow  rules  represent  objectives  for  force  structure  systems 
to  acheive  over  the  period  of  time  for  implementing  VFDMIS. 

3. 4. 5. 2 Proposed  Rules 

a.  Force  structure  data  must  flow  between  HQDA  and  MACOMs  and 
between  MACOMs  and  HQDA  in  an  unconstrained  manner  immediately  following 
each  decision  or  event  that  requires  recording. 

b.  Any  data  flow  constraint  imposed  in  one  force  structure  system 
must  apply  equally  to  other  force  structure  systems. 

c.  Force  structure  systems  must  have,  a periodic  cut-off  of  all 
processing  actions  and  an  established  period  for  reconciliation  and 
balancing  of  the  force  structure  data  base(s)  for  report  purposes.  Such 
reconciliation  and  balancing  should  occur  monthly;  however,  quarterly 
would  be  acceptable. 
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d.  The  reconciled-balanced  force  structure  data  base(s)  would  be 
the  official  source  of  data  for  all  requirements  and  authorizations 
reporting  to  Include  SACS  data  preparation  and  reporting. 

e.  Reconciliation  and  balancing  actions  during  cut-off  periods 
must  resolve  outstanding  (1)  strength  balances  in  the  FORDIMS  FSS  Resource 
Command  Management  Accounts,  and  (2)  AS  data  pending  approval  for  use  in 
FSS. 
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f.  Response  time  standards  must  be  established  for  MACOM  response 
to  guidance,  force  and  command  managers  to  approve/disapprove  MACOM 
response  to  guidance,  and  MACOM  response  to  approved  guidance  through 
TAADS  submission.  These  standards,  once  established,  must  be  built  into 
the  automated  force  structure  systems  together  with  procedures  to  ensure 
adherence  with  them. 

3.4.6  SACS  Initiation 


3. 4. 6.1  Applicability 

The  current  data  processing  request  (DPR)  rules  applicable  to 
initiate  the  SACS  processing  of  the  LOGSACS  and  PERSACS  must  change  from 
the  manually  prepared  DPR,  to  which  USAMSSA  responds,  to  an  automated 
terminal  input  to  which  catalogued  programs  respond. 

3. 4. 6. 2 Proposed  Concept 

a.  Through  the  use  of  interactive  software  and  terminal  hardware, 
the  request  to  freeze  (by  copying)  the  force  and  its  parameters  (EDATE, 
COMPO,  and  FICOD)  will  be  input  via  a keyboard.  Based  on  this  terminal 
input,  the  parameters  would  be  processed  with  software  that  will  copy 
the  appropriate  FORDIMS  files  from  FSS  and  AS. 

b.  As  a part  of  inputting  the  parameters  to  freeze  the  force,  the 
DAMO-FDA  analyst  will  review  the  resource  command  management  account  and 
AS  data  pending  approval  files  and  make  a determination  as  to  whether  or 
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not  actions  are  required  to  resolve  outstanding  data  in  these  files.  This 
review  capability  will  be  automated  so  that  it  provides  output  prior  to 
executing  the  freezing  of  the  force. 


c.  Included  as  a part  of  the  SACS  initiation  process  will  be  load- 
ing the  TOE  file  to  disk.  In  this  process,  the  Parent  Unit  Roll-Up  will 
be  performed,  if  applicable. 


3.4.7  SIGMA  Process 


3.4. 7.1  Applicability 

The  SIGMA  process  is  a part  of  the  initial  SACS  procedures.  It  is 
the  initial  processing  to  prepare  the  force  for  the  LOGSACS  and  the  PERSACS 


3.4. 7.2  Proposed  Concept 

a.  The  future  process  that  replaces  SIGMA  must  be  interactive  and 
must  initiate  via  terminal  the  capabilities  to: 


Review  the  resource  command  management  accounts  and  AS  data 
pending  approval  for  use  in  FSS. 


The  DAMO-FD  and  DAPE-PB  objective  should  be  to  have  zero  strengths  in 
the  resource  command  management  accounts  and  no  transactions  in  the  AS 
data  pending  approval  file,  meaning  that  all  strengths  are  spread  to 
UICs  and  all  AS  documentation  actions  have  been  recorded  in  FSS.  Since 
it  will  be  extremely  difficult  to  achieve  this  objective,  these  two 
important  FSS  suspense-type  actions  must  be  closely  managed  to  ensure 
prompt  resolution  of  pending  actions. 

2 

The  resourced  force  (FICOD  F)  and  the  planning  force  (FICOD  P)  comprise 
the  master  force.  Since  it  is  likely  that  some  FICOD  P units  may  be 
involved  in  each  SACS  run,  the  specific  method  for  processing  planned 
units  must  be  developed. 

^Utilize  a concept  whereby  date  of  last  activity  is  the  factor  to  deter- 
mine whether  the  old  copy  is  still  valid.  Where  no  change  has  been 
processed,  the  date  of  last  activity  would  be  unchanged. 


• Input  parameters  for  loading  the  TOE  file  to  disk  and  In 
the  process  summarize  to  parent  unit  level.  If  required. 

• Review  the  FSS  records  In  conjunction  with  AS  data. 

• Identify  mismatch  and  error  conditions  for  correction; 
transaction  preparation  and  establishment  of  suspense  records 
are  required. 

• Provide  error  messages  and  displays  via  terminal  and/or  hard 
copy. 

• Identify  units  with  plus  and/or  minus  organizational  entities 
and  compare  the  FSS  and  AS  SRC  records  to  categorize  these 
units  as: 

- FSS  and  AS  SRC  match 

- FSS  and  AS  SRC  mismatch 

Those  units  with  FSS  and  AS  SRC  mismatch  will  be  controlled 
by  the  AS  SRCs.  Display  the  results  of  this  match. 

• Initiate  an  audit  to  account  for  all  units  and  their  respec- 
tive detail  data. 

• Identify  TDA  organizations  without  detail  records  for  cor- 
rective actions. 

• Select  the  detail  records  from  the  TOE  file,  as  required, 
always  using  ALO  1 as  "required  quantities"  and  the  actual 
ALO  from  FSS  to  select  the  "authorized  quantities." 

• Generate  transactions  for  corrections  as  required. 

• Perform  the  SRC  assembly  actions  controlling  on  both  FSS 
and  AS  and  display  the  mismatches  via  terminal  and/or  hard 
copy. 

• Check  the  audit  data  to  ensure  that  all  units  are  in  the 
initial  (basic)  SACS  data  base,  that  they  have  personnel 
and/or  equipment  detll  data  selected  from  either  AS  or  TOE. 

• Process  personnel  factoring. 
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Review  for  negative  balances  of  equipment  and  personnel 
prepare  a report  of  such  balances  by  unit  and  eliminate 
the  negative  balances. 


3.4.8  Basis  of  Issue  Plans  (BOIP)  File 


3. 4. 8.1  Applicability 

The  BOIP  file  is  applicable  to  PERSACS , LOGSACS,  and  resource 
impact  analysis. 


3. 4. 8. 2 Proposed  Concept 

a.  The  monthly  BOIP  provided  by  TRADOC  will  not  be  updated  at 

HQDA  and  will  be  used  as  required  to  determine  resource  impact  and  to 

modify  both  the  LOGSACS  and  PERSACS.^  The  responsibility  for  implement 
2 

ing  BOIP  in  PERSACS  will  rest  with  ODCSPER,  whereas  the  responsibility 
for  BOIP  in  LOGSACS  will  remain  with  ODCSOPS. 


b.  The  TRADOC  BOIP  file  must  be  reconciled  with  the  current 
HQDA  BOIP  file  to  ensure  that  no  data  is  lost  in  changing  to  the  TRADOC 
BOIP. 


c.  The  BOIP  processing  will  be  separate  from  all  other  SACS 
processing.  This  capability  must  provide  resource  impact  displays  for 
ARSTAF  analysis.  The  software  to  be  developed  must  be  interactive  and 
BOIP  processing  results  will  be  displayed  via  terminal  or  hard  copy 
reports.  The  processing  will  be  flexible  so  that  either  all  or  only 
selected  SRCs  that  match  a BOIP  may  be  changed  or  all  SRCs  may  be  changed 


'The  BOIP  data  do  not  reflect  numbers  of  personnel  to  be  authorized  at  the 
various  authorized  levels  of  organization  (ALO) . This  is  a deficiency  in 
the  current  BOIP  data.  Also,  FICOD  F (recourced)  units  may  have  the 
number  of  authorized  military  spaces  increased  from  the  FSS  constrained 
number.  This  difference  must  be  identified  as  not  resourced. 


Regardless  of  ARSTAF  involvement,  BOIP  processing  in  PERSACS  must  be 
devleoped  and  implemented  as  soon  as  possible  to  improve  projected 
personnel  requirements  and  authorization  data  provided  MILPERCEN. 


based  on  a percentage  factor.  A BOIP  control  file  will  trigger  the  type 
processing  on  an  exception  basis.  For  example,  entering  a BOIP  number 
on  the  control  file  with  appropriate  criteria  would  establish  processing 
constraints,  whereas  no  BOIP  numbers  on  the  control  file  would  permit 
unconstrained  BOIP  processing. 

d.  The  BOIP  file  and  its  processes  should  be  modified  to  encompass 
the  identification  of  trade-off  personnel  spaces  when  the  trade-off  is 
outside  of  a single  SRC. 

s.  The  BOIP  software  must  be  established  for  daily  use  and  it 
must  accommodate  the  ODCSOPS  needs  of  DAMO-RQ  and  DAMO-FD  so  that  re- 
source impact  data  are  based  on  identical  logic/ software  rather  than 
different  logic/software  as  is  the  present  practice.  The  HQDA  BOIP 
resource  impact  processing  should  be  the  basis  for  all  HQDA  BOIP-related 
reports.  The  TRADOC  BOIP-related  reports  prepared  for  the  ARSTAF  should 
be  discontinued  at  the  time  that  the  HQDA  BOIP  processing  is  implemented. 

3.4.9  Table  of  Organization  and  Equipment  (TOE)  File 

3. 4. 9.1  Applicability 

The  TOE  file  is  applicable  to  PERSACS,  LOGSACS  and  the  assemblying 
of  SRC  detail  data. 


3. 4. 9. 2 Proposed  Concept 

The  TOE  file  presently  provided  to  HQDA  by  TRADOC  is  updated  by 
USAMSSA  to  develop  the  TOE  computational  file  for  SACS.  A principal 
part  of  the  USAMSSA  processing  is  to  aggregate  all  subunit  data  to 
parent  unit  level.  This  processing  should  be  a part  of  the  TRADOC  TOE 
file  maintenance  processing  so  that  HQDA  is  provided  a useable  TOE  file 
that  can  be  direct  SACS  input  without  updating.  By  placing  this  require- 
ment on  TRADOC,  a single  authoritative  source  for  the  TOE  file  will  be 
es tablished. 


3.4.10  Short  Hand  Notes  (SHN) 


3.4.10.1  Applicability 

The  SHN  file  and  processing  are  applicable  to  both  PERSACS  and 
LOGSACS. 

3.4.10.2  Proposed  Concept 

a.  The  SHN  will  represent  ARSTAF  desires  with  respect  to  modifying 
PERSACS  and  LOGSACS  output  data.  The  development  and  implementation  of 
improved  SHN  processing  will  continue  to  be  an  ODCSOPS  responsibility  for 
LOGSACS;  however,  it  will  be  an  ODCSPER  responsibility  for  developing 

and  implementing  SHN  in  PERSACS. 

b.  The  SHN  file  must  be  developed  so  that  data  can  be  input  and 
changed  via  a terminal.^  The  data  must  accommodate  one-time  and  multi- 
use records  for  application  to  UIC  and  SRC. 

c.  The  SHN  concept  has  application  to  both  PERSACS  and  LOGSACS; 
however,  because  of  data  differences  between  the  detail  records  of 
PERSACS  and  LOGSACS,  the  logic  of  applying  personnel  SHN  may  significantly 
vary  from  that  for  equipment  SHN.  Therefore,  one  SHN  system  will  not 
apply  to  both  the  PERSACS  and  LOGSACS. 

3.4.11  Phasing 

3.4.11.1  Applicability 

The  phasing  of  equipment  and  personnel  into  units  must  be  on  a 
coordinated  schedule  and  is  applicable  to  the  SACS  system. 

3.4.11.2  Proposed  Concept 

a.  The  data  for  building  an  equipment  phasing  file  (EQPF)  will 
originate  at  DESCOM  from  the  phased  equipment  module  (PQ1)  and  should  be 

^Automated  file  update  capability  must  be  developed  to  handle  SB700-20 
and  MOS  changes. 


provided  on  a quarterly  basis,  as  a minimum.  The  PEM  module  Is  scheduled 
for  implementation  in  January  1980. 

b.  The  EQPF  must  be  used  by  ODCSPER  to  phase  personnel  require- 
ments and  authorizations  so  that  the  personnel  availability  will  coincide 
with  equipment  availability. 

c.  The  EQPF  may  be  used  by  ODCSOPS  to  record  the  projected  equip- 
ment availability  date  with  applicable  UIC  and  LIN  data  since  EQPF  data 
may  influence  unit  EDATE.  This  phasing  data  will  be  available  to  force 
and  command  managers  for  periodic  review  and  change  of  EDATE  based  on 
equipment  availability. 

3.4.12  Reimbursable  Personnel  Authorizations 

3.4.12.1  Applicability 

The  identification  of  reimbursable  personnel  is  applicable  to 
VFDMIS,  FORD IMS,  TAADS,  ITADDS,  and  SACS. 


3.4.12.2  Proposed  Concept 

a.  The  documentation  of  reimbursable  personnel  can  best  be 
accomodated  through  the  Army  Management  Structure  (AMS)  by  using  OSD 
program  element  91519A. 


b.  The  allocation  of  resources  under  FORDIMS  and  the  documenta- 
tion of  resources  in  TAADS  through  the  use  of  the  guidance  tracking  pro- 
cedure will  provide  ODCSPER  and  MILPERCEN  with  positive  identification 
of  reimbursable  personnel  positions. 


^PE  91519A  currently  has  both  officer  and  enlisted  spaces  authorized  in 
both  FY79  and  FY80  in  the  FYDP.  Since  this  PE  is  not  currently  used 
in  the  AMS,  this  manpower  must  be  documented  in  other  AMS  codes.  Not 
only  does  this  preclude  identifying  reimbursable  personnel  spaces,  it 
also  distorts  and  contributes  to  the  inability  to  balance  AMS  code 
resources  to  the  respective  FYDP  PEs. 
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3.4.13  TDA  Augmentation  Units  to  MTOE  Units 

3.4.13.1  Applicability 
The  TOE  unit  augmentation  identification  is  applicable  to  VFDMIS 

and  FORD IMS. 

3.4.13.2  Proposed  Concept 

The  unit  actions  taken  concerning  TDA  augmentation  are  often  out 
of  synchronization  with  the  parent  unit  being  augmented.  Therefore,  each 
time  a unit  change  is  processed,  four  positions  of  UIC  should  be  reviewed 
automatically  in  all  other  TDA  units  to  determine  if  an  augmentation 
exists  for  the  unit.  If  an  augmentation  unit  exists,  appropriate  EDATE 
change  or  other  action  must  be  taken  to  align  the  augmentation  with  the 
MTOE  unit  being  changed. 

3.4.14  Input  of  Detail  Data  at  HQDA 

3.4.14.1  Applicability 
The  input  of  detail  data  at  HQDA  is  applicable  to  VFDMIS,  FORDIMS, 

TAADS,  and  SACS. 

3.4.14.2  Proposed  Concept 

a.  In  instances  where  change  must  be  immediately  reflected  in 
the  HQDA  force  structure  systems  or  when  a resource  command  fails  to 
provide  documentation  within  established  time  standards,  HQDA  will  input 
the  necessary  detail  data  and  advise  the  resource  command  accordingly. 

b.  SACS- identified  deficiencies  could  be  handled  in  this  same 
manner  and  thus  possibly  reduce  the  use  of  and  need  for  SHN. 

3.4.15  TAADS  Documents  Review 

3.4.15.1  Applicability 

The  TAADS  documents  review  is  applicable  to  VFDMIS,  FORDIMS,  and 
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TAADS. 


3.4.15.2  Proposed  Concept 

Section  II  (Personnel)  of  TAADS  documentation  Is  currently 
reviewed  In  ODCSPER  (DAPE-MBA) . This  section  contains  personnel  detail 
data  such  as  MDS,  grade,  title,  ASI,  and  remarks.  The  Section  II  review 
could  be  improved  and  strengthened  to  ensure  compliance  witn  AR  611-101, 

AR  611-201,  and  other  guidance.  Figure  3.1  reflects  the  current  TAADS 
document  flow.  Figure  3.2  depicts  a proposed  change  in  the  TAADS  document 
flow  to  reflect  a personnel  review  activity  which  should  be  established 
(at  MILPERCEN  perhaps)  and  that  would  be  on  a comparable  basis  with  the 
US  Army  Equipment  Authorization  Review  Agency  (USAEARA) . This  new 
activity  would  assure  the  responsiblity  for  TAADS  document  review  and 
relieve  DAPE-PBA  personnel  so  they  could  concentrate  on  their  command 
management  and  other  responsibilities. 

3.4.16  Complete  LOGSACS  and  PERSACS  Data  Base 

3.4.16.1  Applicability 

The  complete  LOGSACS  and  PERSACS  data  base  is  applicable  to  VFDMIS, 
FORD IMS,  and  SACS. 

3.4.16.2  Proposed  Concept 

a.  The  improved  on-line  SACS  will  develop  a complete  requirements 
and  authorizations  data  base  that  reflects  all  unit  actions,  modernization 
actions,  and  equipment  and  personnel  phasing. 

b.  This  data  base  should  become  the  Army's  single  authoritative 
source  for  all  reports  concerning  personnel  and  equipment  requirements 
and  authorizations.  This  will  ensure  that  all  users  of  these  data  have 
identical  figures. 

c.  The  list  of  reports  in  Appendix  C is  now  prepared  from  FORDIMS 
AS.  These  are  candidate  reports  for  the  future  SACS  data  base,  since 
currently  they  do  not  necessarily  reflect  complete  data.^ 


F.  0.  Deppner  et  al. , Report  of  Task  C - Data  Analysis  of  Accuracy  and 
Timeliness,  General  Research  Corporation,  1070-02-79-C , March  1979, 
p.  G-3. 
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Figure  3.1.  Current  Flow  of  TAADS  Documents  (MTOE  and  TDA) 


3.4.17  SACS  His to 


3.4.17.1  Applicability 

The  SACS  history  is  applicable  to  SACS,  Personnel  Authorizations 
Analysis  System  (PAAS) , and  Basis  of  Issue  Monitoring  and  Recording  Sys- 
tem (BOIMARS). 

3.4.17.2  Proposed  Concept 

a.  After  each  SACS  (LOGSACS  and  PERSACS  generation),  a magnetic 
tape  copy  of  the  LOGSACS  and  PERSACS  will  be  created  and  archived  for 
future  analytical  use.  SACS  history  should  be  maintained  for  at  least 

7 years  based  on  CY,  BY,  PY,  plus  4 out  years. 

b.  The  history  files  would  be  used  by  PAAS  and  BOIMARS  and  for 
other  analytical  purposes,  such  as  inquiries,  researching  past  require- 
ments, comparing  current  requirements  to  similar  past  requirements. 

3.4.18  SACS  Documentation 


3.4.18.1  Applicability 

SACS  documentation  requirements  are  applicable  to  VFDMIS,  FORDIMS, 
TAADS , BO IP , TOE,  EQPF,  and  other  systems  that  interface  with  SACS. 

3.4.18.2  Proposed  Concept 

a.  Complete  documentation  is  required  to  be  used  in  day-to-day 
operations  by  personnel  that  either  work  directly  with  SACS  or  with  SACS 
products. 

b.  SACS  documentation  as  a minimum  should  consist  of: 

• A force  structure  systems  "data  element  directory"  which 
should  contain  descriptions,  character  length  and  type, 
components,  values,  and  system  use  for  each  data  element. 

• A SACS  Functional  Users'  Guide  which  would  be  specifically 
oriented  for  users  of  SACS  data  and  products  outside  ODCSOPS. 


o A SACS  Systems  and  Procedures  Manual  which  would  be  oriented 
for  SACS  Branch  personnel  (DAMO-FDA) . 

c.  SACS  documentation  should  encompass  a full  briefing  or  train- 
ing course  concerning  force  development,  force  maintenance,  use  of  force 
data,  and  the  pervasive  nature  of  force  data  as  produced  by  the  SACS. 

d.  The  improved  on-line  SACS  should  be  documented  by  ADP  documen- 
tation standards  published  in  DOD  Standard  7935. 1-S,  Automated  Data  Systems 
Documentation  Standards.  These  standards  specify  that  documentation  should 
consist  of: 


e Functional  Description 

e Data  Requirements  Document 

# System/Subsystem  Specification 

e Program  Specification 

e Other  documents  as  required 

3 . 4 . 19  Changes  to  Existing  Data  Elements 

3.4.19.1  Applicability 

The  data  elements  that  are  required  by  the  functional  users  must 
be  provided  by  the  VFDMIS,  FORDIMS,  TAADS,  TOE,  BOIP,  EQPF,  and  SACS  in 
SACS  data  and  products. 

3.4.19.2  Needs 

a.  Where  unit  activations  are  being  coordinated  with  unit  deac- 
tlvations,  an  audit  trail  to  reflect  the  old  UIC  is  required  so  that  both 
the  personnel  and  logistics  function  can  effectively  and  efficiently 
distribute  the  assets  of  the  discontinued  unit(s). 

b.  A list  identifying  POMCUS  equipment  is  needed  so  that  SACS 
equipment  detail  data  include  such  identification.  The  POMCUS  equipment 
list  must  be  developed  by  ODCSOPS,  ODCSLOG,  and  ODCSRDA  with  ODCSOPS 
(DAMO-RQ)  taking  principal  responsibility.  These  data  must  be  applicable 
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for  ac  least  1 year  and  should  be  projected  for  3 to  5 years,  so  that 
turbulence  Is  held  to  a minimum  in  positioning  POMCUS  stocks. 


c.  The  minimus  requirements  for  training  purposes  must  be  associated 
with  equipment  requirements.  ODCSRDA  needs  to  properly  compute  equipment 
requirements  for  training.  The  data  element  would  likely  be  a variable 
percentage  factor  baaed  on  the  amoimt  of  equipment  use  during  training.^ 


d.  The  additional  skill  identifiers  and  the  language  identification 
codes  must  have  their  own  data  fields  in  TAADS,  FORD IMS,  and  SACS  so  that 
personnel  reisarks  codes  are  not  distorted  and  all  coded  special  require- 
ments are  provided  to  personnel  managers. 


e.  The  security  investigation  status  code  (SISCO)  should  be  a 
required  entry  for  all  authorized  positions  with  a code,  such  as  NN, 
meaning  that  no  SISCO  applies  to  this  position.  The  SISCO  should  be  a 
stand-alone  data  field  and  not  included  in  the  position  remarks  data 
element  field. 

f.  Complete  descriptive  data  are  requred  for  geographically  split 
organizations.  In  this  respect,  HQDA  policy  published  in  AR  310-49 
series  regulations  on  TAADS  requires  change.  Also,  the  documentation 

of  functionally  and  geographically  split  organizations  has  separate 
descriptive  designators  assigned;  however,  the  system  provides  no 
discriminator  to  differentiate  between  these  two  different  types  of 
split  organizations.  Also,  KTOE  organizations  that  are  geographically 
split  but  assigned  to  the  same  coonand  are  not  documented  separately. 
Complete  descriptive  data  to  include  ARLOC,  GELOC,  and  L0CC0  are  required 
for  each  element  of  all  organizations  that  are  geographically  separated 
from  each  other.  This  requirements  is  for  distribution  of  both  personnel 
and  equipment . 

*A  study  of  training  equipment  needs  is  currently  under  way  within  ODCSRDA. 
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g.  Selected  quantity  fields,  when  output  on  magnetic  tape  for  the 
LOGSACS  and  PERSACS,  are  currently  coded  with  binary  represented  numbers. 
This  requires  translation  each  time  they  are  utilized.  On  some  computers, 
because  of  various  uniqueness,  this  presents  technical  difficulties  in 
performing  the  translation.  Quantity  fields  should  be  coded  as  all  other 
digital  data  regardless  of  whether  it  is  alphabetical  or  numerical.  This 
will  facilitate  the  use  of  SACS  generated  magnetic  tape  and  the  programming 
of  software  for  all  users. 

h.  The  enlisted  MOS  code  (MOSCO)  is  identified  in  AR  611-201  as 
a 5-position  code  which  includes  the  skill  (3  positions),  skill  level  (1 
position),  and  the  special  qualifications  (1  position).  FORDIMS  identifies 
the  MOS  as  a 4-position  code  and  the  special  qualifications  code  is  handled 
in  a 1 position  field  separated  from  the  4 positions.  Departures  from  stan- 
dard data  use  cause  more  logic  and  computer  program  coding  to  be  written, 
debugged,  and  implemented  for  systems.  The  MOS  standard  as  well  as  all 
data  element  standards  must  be  adhered  to. 

3.4.20  Data  Synchronization 


3.4.20.1  Applicability 

Data  synchronization  is  required  between  all  interfacing  force 
structure  systems  or  files.  They  are  VFDMIS,  UIS,  FORDIMS,  TAADS,  TOE, 

BO IP,  SHN,  and  EQPF. 

3.4.20.2  Proposed  Concept 

a.  Control  data  elements  are  used  for  interfacing  or  sequencing 
records.  Such  data  elements  are  UIC,  SRC,  CCNUM,  MOS,  LIN,  AMSCO,  and 
other  similar  ones  that  identify  some  unique  aspect  of  a data  record. 
These  data  elements  must  always  agree  in  each  file  where  they  are  stored. 

b.  Changes  to  data  values  that  are  periodically  published,  such 
as  SB  700-20  (LIN),  MOS,  and  AMSCO  changes,  must  be  Implemented  in  all 
files  on  a coordinated  schedule  so  that  all  records  of  Interfacing  sys- 
tems match  at  all  times. 
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c.  UIC  and  SRC  editing  and  control  must  be  installed  and  effec- 
tively managed  in  all  systems.  This  must  encompass  the  plus  and  minus 
actions  to  specific  units. 

d.  CCNUM  is  a numerical  document  control  number  assigned  by  each 
MACOM  to  TAADS  documents.  Controls  must  be  implemented  to  ensure  that 
once  a CCNUM  is  used  it  cannot  be  reused. 

3.4.21  PAAS  and  BOIMARS 

3.4.21.1  Applicability 

These  SACS  data  analyzers  are  applicable  to  PERSACS  and  LOGSACS. 

3.4.21.1  Proposed  Concept 

a.  These  analyzers  should  be  upgraded  to  be  a part  of  the  overall 
audit  concept  for  SACS  data. 


b.  Both  PAAS  and  BOIMARS  should  be  programmed  to  be  used  in  either 
on-line  or  batch  mode. 


c.  These  analyzers  should  be  upgraded  to  include  mathematical 
analysis  techniques  such  as  computing  a moving  average  and,  if  the  change 
exceeds  a specified  percentage,  reviewing  the  detail  data  or  computing 
a standard  deviation  and,  if  it  exceeds  the  specified  acceptable  deviation, 
reviewing  the  detail  data. 

3.4.22  System  Back-Up/ Restore  Capabilit 


3.4.22.1  Applicability 

The  improved  on-line  SACS  requires  a system  back-up  and  restore 
capability. 


The  on-line  concept  presupposes  that  the  previous  LOGSACS  or  PERSACS 
can  be  loaded  to  disk,  hence  disk  storage  space  must  be  available  for 
on-line  operation. 


3.4.22.2  Proposed  Concept 

a.  A system  back-up  and  restore  capability  must  be  built  into  the 
improved  SACS  software  to  accommodate  saving  work  files  as  well  as  entire 
files  on  a periodic  basis.  This  will  ensure  that  significant  blocks  of 
interactive  work  are  not  lost  because  of  system  or  other  failure. 

3.4.23  Organizational  Structure 

3.4.23.1  Applicability 

The  principal  force  structure  actions  are  taken  in  DAMQ-FDF  and 
DAMO-FDP. 


3.4.23.2  Proposed  Concept 

a.  Force  management  for  all  years  (CY,  BY,  PY  and  out  years)  must 
be  vested  in  a single  individual  or  group  of  individuals. 

b.  The  same  UIC  generally  has  record  entries  applicable  to  the 
CY  and  BY  which  are  the  responsibility  of  DAMO-FDP,  and  record  entries 
applicable  to  the  program  years  which  are  the  responsibility  of  DAMO-FDF. 
This  current  operational  concept  leads  to  unintential  disconnects  in  force 
structure  actions  which  could  be  avoided  by  periodically  reviewing  unit 
actions  across  all  years. 
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ASSUMPTIONS 


The  on-line  SACS  will  continue  as  the  principal  system  to  provide 
a periodic  statement  of  equipment  and  personnel  requirements  and 
authorizations  to  the  Army  for  distribution  and  planning  actions 
at  all  echelons. 


2.  Current  LOGSACS  and  PERSACS  products  will  remain  essentially  unchanged 


Future  SACS  processes  will  consist  of  on-line  and  batch-type  soft 
ware  to  be  utilized  and  initiated  interactively  via  terminal. 


OOCSOPS  will  initiate  action  to  establish  a Force  Structure  System 
Configuration  and  Control  Group. 


5.  Development  of  the  improved  on-line  SACS  will  Impact  functional  user 
systems  minimally. 


Force  Structure  guidance  flow  will  not  require  modification  to 
support  an  on-line  SACS,  except  that  EDATE  rules  and  top-of-system 
detail  data  loading  capability  should  be  Implemented. 


SACS  feeder  systems  will  remain  unchanged;  except,  they  will  be 
improved  to  accommodate  revisions  to  rules,  controls,  edits,  and 
"top-loading"  of  detail  data  and  except  that  VFDMIS  will  supersede 
FORD IMS. 


8.  Application  of  BOIP  and  SHN  in  LOGSACS  will  remain  an  ODCSOPS 
responsibility. 


Implementation  of  BOIP  and  SHN  in  PERSACS  is  an  ODCSPER  responsibility 
however,  ODCSOPS  will  develop  the  basic  PERSACS  and  ODCSPER  will 
develop  BOIP  and  SHN  systems  to  be  compatible  with  the  basic  PERSACS. 


10.  Future  availability  of  the  TRADOC  BOIP  file  will  be  monthly;  it  will 
be  used  without  USAMSSA  updating  for  purposes  of  resource  impact 
and  SACS  processing.  SHN  resource  Impact  will  be  an  integral  part 
of  overall  resource  Impact  determinations. 


11.  The  TOE  file  will  be  provided  monthly  by  TRADOC;  it  will  be  used 
in  SACS  processing  without  USAMSSA  updating,  if  practical. 

12.  Future  SACS  processes  will  be  modularized  by  function  for  either 
stand-alone  or  job-stream  processing. 

13.  Future  SACS  processes  will  utilize  record  control  and  accounting 
techniques  to  assure  that  output  products  consist  of  all  units  and 
their  respective  personnel  and  logistics  detail  records. 

14.  Retrieval  capability  will  be  made  available  to  functional  users, 

as  required,  based  on  security  constraints  and  hardware  limitations. 

15.  On-line  SACS  software  will  not  require  significant  alteration  when 
FORDIMS  is  superseded  by  VFDMIS  providing  fundamental  changes  are 
not  made  to  data  elements. 

16.  Functional  coordination  software  will  be  required  to  interface  the 
phasing  of  equipment  and  personnel  requirements  and  authorizations 
to  determine  if  asset  shortfall  Is  projected  for  a future  date. 

17.  Current  USAMSSA  hardware  will  be  utilized  as  the  on-line  SACS 
hardware;  additional  terminals  may  be  required  in  ODCSOPS  and 
ODCSPER. 
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TIMELINESS  REQUIREMENTS  AND  DEFINITIONS 


Data  elements  and  their  timeliness  requirement  are  related  to  resource 
distribution  since  chanties  to  data  elements  change  resource  requirements 
which  require  functional  user  response.  Functional  user  response  requires 
time.  That  time  is  identified  as  "functional  time"  for  Category  II  and  III 
data  elements,  described  below.*-  Therefore,  as  data  elements  are  initially 
established  and  subseque  -Ely  changed,  personnel  making  changes  must 
be  cognizant  of  the  requl  ament  to  project  resource  change  actions  suffi- 
ciently into  the  future  sc  as  to  provide  the  functional  users  the  required 
response  time. 

To  implement  the  foregoing,  data  element  end  use  must  be  known.  Re- 
gardless of  why  data  are  initially  established  or  changed,  the  personnel 
responsible  for  formulating  the  initial  or  change  data  must  be  cognizant 
of  the  resultant  functional  actions  that  are  triggered  because  of  such 
data.  In  order  to  provide  initial  guidance  for  this  purpose,  SACS  data 

elements  have  been  grouped  in  three  categories . Each  category  and  its 

2 

initial  data  element  assignments  are: 

Category  I:  This  category  contains  data  elements  which  are  used  in 
force  structuring,  control.  Internal  processing,  accounting,  unit  identifi- 
cation, and  general  functional  support  information.  These  data  elements 
are  included  in  the  SACS  computation  and  are  provided  to  functional  users 
via  the  LOGSACS  and  PERSACS.  The  timeliness  requirement  is  that  Category 

1 data  elements  be  available  in  each  quarterly  SACS  product.  Category  I 
data  elements  may  be  established  or  changed  at  any  time.  Category  I data 
elements  are: 

*"In  addition  to  functional  time,  "system  time"  must  be  included  so  that  time 
for  data  flow  and  processing  is  provided.  Together,  these  time  periods 
equal  the  projected  time  or  the  amount  of  time  necessary  to  project  changes 
to  provide  the  required  response  time  from  the  functions  utilizing  LOGSACS 
and  PERSACS  data. 

2 

Data  elements  and  mnemonics  are  defined  in  Report  of  Task  D - Data  Require- 
ments Document.  General  Research  Corporation,  1070-03-79-CR,  May  1979. 


ACTCO 


ELSEQ 

ERCOD 


MBLOC 


PRQTA 

PRQTO 

RCNUM 

REPCO 


ADCON 


MBPRD 


AMSCO 


FICOD 


MBSTA 


ARLOC 


FNCAT 


NTREF 


AUTHR 


FORCO 


OPAGY 


ROBCO 


BASIS 


OPDAT 


JCSTY 


SORCE 


BRNCH 


LAOTH 


PAUBO 


SRCTO 


LAUBO 


PAUSH 


STAFA 


CATCO 


LAUSH 


PAUTA 


STATS 


CCNUM 


PAUTO 


LAUTA 


TPSNA 


CHGNR 


LAUTO 


PECOD 


TYPCO 


COMPO 


LRBOI 


POMCL 


UICOD 


DAMPL 


LROTH 


POMCU 


UNCLC 


DAPPL 


LRSHN 


PRBOI 


UNMBR 


DOCNO 


LRTAD 


PRMK1 

PRMK2 

PRQSH 


UNTDS 


DPMNT 


LRTOE 


DSCMP 


MBCMO 


Category  II:  This  category  identifies  data  elements  which  impact 
resources.  Projections  must  be  made  based  on  system  and  functional 
response  times.  These  data  elements  are  used  to  validate  authorizations 
and  to  distribute  equipment  and  personnel.  When  a force  or  command  mana- 
ger at  HQDA  or  MACOM  establishes  or  changes  a data  element  in  this  category 
the  EDATE  must  be  advanced  far  enough  into  the  future  to  allow  for  the 
system  and  functional  response  time  for  logistics  and  personnel  actions 
to  be  completed  within  the  projected  time  frames.  The  projected  time 
(in  months)  for  Category  II  is  given  in  Table  B.l.  The  associated  data 
elements  are: 

AS ICO  ID ENT  PAMIL  REQEQ 

AUBFA  LICCO  PAOFF  RQSTR 

AUSTR  LINUM  PAWOF  SPLIT 

AUTEQ  LOCCO  PRCIV  SQICO 

BPTRI  MACOM  PRENL  STNNM 

BRNCP  MOSCO  PRMIL  TDATE 

EDATE  PACIV  PROFF  UNPID 

GRADE  PAENL  PRWOF 


CATEGORY  II  PROJECTED  TIME  (MONTHS) 


System 

Times 

Functional 

Time 

Projected 

Time 

LOG 

CONUS 

7.5 

b 

7.5 

LOG 

Overseas 

7.5 

b 

7.5 

PER 

CONUS 

7.0 

6.0 

13.0 

PER 

Overseas 

7.0 

9.0 

16.0 

This  is  a maximum  time  requirement  based  on  making  changes 
the  day  after  the  MOC  window  closes.  This  time  requirement 
can  be  reduced  as  data  are  established  or  changed  within 
the  6-month  interval  between  closing  and  opening  of  the 
semiannual  MOC  windows.  The  time  may  contract  or  expand 
depending  on  data  flow  and  system  processing  changes  that 
impact  time  requirements. 

The  order-ship  time  requirements  may  be  specified,  if  appli- 
cable, in  the  use  of  SACS  data.  These  must  be  defined  by 
ODCSLOG. 


Category  III:  This  category  contains  data  elements  which  impact 
resources.  Projections  must  be  made  based  on  system  and  functional 
response  time.  These  data  elements  are  used  primarily  for  modernization, 
phasing,  recruiting,  training,  and  mid-  and  long-range  planning.  When 
force  and  command  managers  and  other  HQDA  staff  planners  incorporate  changes 
in  the  force  in  the  out  years,  the  EDATE  established  for  these  data  ele- 
ments must  be  advanced  far  enough  into  the  future  to  allow  for  system  and 
functional  response  time  plus  the  additional  lead-time  requirements1 
associated  with  logistic  actions  and  the  recruitment,  training,  distribu- 
tion time  for  personnel.  The  projected  time  requirements  (in  months)  for 
Category  III  are  given  in  Table  B.2.  The  associated  data  elements  are: 

^The  specific  lead  time  requirements  must  be  published  by  ODCSLOG  and 
ODCSPER  and  implemented  by  command  and  force  managers  and  MACOM. 


AS  ICO 

GRADE 

PAMIL 

PRWOF 

AUBFA 

ID  ENT 

PAOFF 

REQEQ 

AUSTR 

LICCO 

PAWOF 

RQSTR 

AUTEQ 

LINUM 

PRC  IV 

SQICO 

BPTRI 

MOSCO 

PRENL 

BRNCH 

PACIV 

PRMIL 

EDATE 

PAENL 

PROFF 

Table  B.2 

CATEGORY  III  ] 

PROJECTED  TIME  (MONTHS) 

System 

Functional 

Projected 

Time3 

Time 

Time 

LOG  CONUS 

7.5 

b 

7.5 

LOG  Overseas 

7.5 

b 

7.5 

PER  CONUS 

7.0 

24.0 

31.0 

PER  Overseas 

7.0 

27.0 

34.0 

£ 

See  note 

a, 

Table  B.l. 

'’See  note 

b. 

Table  B.l. 
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Customer 


Concrol  No 


•fA AM  Detail  AvUcloa  Report 


PG-0113-74  Monthly  Validation  of  aviator  poaltlona  In  approved  MTOE  and  TDA 

documents 

PH-0588-75  Quarterly  Datall  data  of  offlcar  poaltlona  to  Offlcar  Personnel  Manage- 
ment Dlractorata 

PC-0210- 76  Sami -Annual  Uaad  to  valldata  requirements  for  apaclflc  akllla  In  tha 

Spaclal  and  Management  Program 

PH-0890-76  Monthly  Uaad  to  aaalgn  chaplalna  by  ASI  and  position  dascrlptlon 

PG-004A-77  Quartarly  Uaad  to  determine  tha  nuabara  of  Foralgn  Araa  Offlcar  (FAO) 

apaclallata  naadad  to  aaat  Amy  requirements 

PH-0022-78  Quartarly  Uaad  for  analyatJ  of  requirements  (COMPO  1,  2,  and  3)  for 

chaplalna 

PH-0051-78  Monthly  Provlda  data  on  club  managamant  poaltlona  In  TDA  and  MTOE 

unlta 

PH-0345-78  Quarterly  Uaad  by  tha  Training  Aaalgnnent  Branch  to  valldata  training 

raquaata 

PH-0093-79  Monthly  Uaad  to  analyse  raqulraaanta  for  offlcar  and  anllatad  NBC 

apaclallat 

Nona  Aaalgnad  Aa  Requested  Uaad  for  analyela  of  requlreaanta/authorlcatlona  for  aelected 
MOSa 

Nona  Aaalgnad  Aa  Raquaatad  Obtalna  a copy  of  an  official  approvad  Unit  Authorisation 

Document;  primarily  for  dlatrlbutlon  to  aacallltad  common da 
by  OAMO-PDU 

PH-0034-72  Seal-Annual  Uaad  to  dataralna/varlfy  total  TDA  requireaancs  for  enllstad 
par aonnal  by  M OS,  duty  position,  branch,  and  grade 

PH-0220-75  Monthly  Uaad  to  analysa  changes  in  Active  A ray  poaltlona  deaignated 

for  chaplalna 

PH-0530-75  Quarterly  Uaad  by  HQ  US  Ar ay  Missile  Coam*a4  to  asnaga  MOS  35H  and  35B 

PC-0096-76  Quarterly  Uaad  to  analyte  offlcar  personnel  raqulraaanta  by  Position 

Specialty  Coda  (PSC) 

PC-0029-76  Seal-Annual  Uaad  for  determining  ROTC  Input  raqulraaanta 

PC-0191- 76  Monthly  Provides  suaaery  data  on  tha  authorised  strength  of  the 

Active  Any,  Any  Reserve,  and  Any  National  Guard 

PE-019 3- 76  Seal-Annual  Used  to  determine  maxlaua  number  of  positions  in  USAA  units 

to  which  feaales  can  be  aaalgnad 

PH-0313-76  Monthly  Used  to  detanlne  total  number  of  Active  Any  aviators  that 

are  required  and  authorised 

PH-0674-76  Quarterly  Used  in  the  personnel  management  of  JAG  OFT/WO 

PC-002 1-7 7 Semi-Annual  Used  to  manage  the  Reserve  Component  Objective  Force 

PC-0056- 77  Quartarly  Uaad  to  manage  tha  Reserve  Component  Objective  Force 

PC-OOOl-72  Monthly  Provides  information  of  co»erclel-deslgn  administrative 

motor  vehicles  (AMV)  for  use  by  DCSLOG  Transportation 
Management  Division 

PH-0608-72  Monthly  Provides  Information  to  DCS LOG  Transportation  Management 

Division  on  military  design  AMV 

PC-0022-74  Seal-Annual  Provides  data  concerning  authorised  admlnlatratlve  use 

vehicles  In  Active  Army,  USAR.  and  ARKC  TDA  units 

PC-0023-74  Seal-Annual  Provides  deta  on  authorised  tactical  vehicles  In  Active  Army, 

USAR.  end  ARJtG  TDA  units 

PH-0222-74  Quartarly  Provides  data  on  cMaerclal  design  vehicles  by  the  US  Army 

Tank  Autoaotlve  Canter 

PH-0343-74  Quartarly  Provides  information  on  raqulrod  and  authorised  aircraft 

quantities  and  wo  positions  In  Active  Army  units 

PH-0377-76  Quartarly  Uaad  to  support  World-Wide  Aviation  Logistics  Conference 


*TAADS  Detail  ASI  (PSC)  Extract 


Detail  Chaplain  PSC  Report 
Forelgm  Araa  Spacialiata 


Chap la la  MOS  Extract  TDA/ MTOE 


MOS /Duty  Position  Report 


•TAADS  Monthly  Changes  to  Chaplains 


"Redstone  Arsenal  TAADS  MOS  Extract 


Officer  PSC  Sumaary  Report 


USA!  Offlcar  Branch  and  Crada  Report 

•TAADS  Authorized  Strength  by 
Component 

USA*  Nnla/Famnla  Interchangeable 
Report 

Aviator  Poaltlona  Racap  05  and 
Below 

JAG  Off Icar/Werranc  Extract 
vJLNG  Officers  by  Branch  and  Grada 
USA!  SSZ  and  Grada  Report 
Coeaerlcal  Design  Vehicle  Extract 


Military  Design  Vahlcla  Extract 


TDA  Admlnlatratlve  Use  Vehicles 


TDA  Tactical  Vehicles 


•TAADS  SSN/L1N  Report 


Alrcraft/Avlacor  Retrieval 


•TAADS  Aircraft  Retrieval 


•Indicates  chat  the  word  TAADS  should  bo  eliminated 


VFDMIS  PLANNED  IMPROVEMENTS 


The  Vertical  Force  Development  Management  Information  System  (VFDMIS) , 
which  is  currently  under  development  by  the  US  Army  Computer  Systems  Command 
(CSC),  is  the  first  force  systems  major  upgrade  effort  since  implementing 
the  Force  Accounting  System  (FAS)  and  The  Army  Authorization  Documents 
System  (TAADS).  The  VFDMIS  concept  encompasses  a common  force  data  base 
where  all  force  files  will  be  linked  through  data  base  technology  in  a 
computer  environment  and  accessible  by  HQDA  force  and  command  managers, 
MACOM,  and  installations  located  in  CONUS  and  overseas.  The  concept  in- 
cludes capabilities 


Process  both  wartime  and  peacetime  requirements  and  authoriza' 
tions  data  for  personnel,  materiel,  and  funds. 


Provide  for  initial  mobilization  and  build-up  data  to  include 
deployment  and  contingency  planning  data. 


Provide  for  expansion  to  accommodate  newly  activated  installa' 
tions . 


Provide  asset  and  casualty  and  equipment  combat  loss  data 


Provide  information  and  data  for  management  within  manpower 
budgeting,  and  force  constraints. 


Provide  for  readiness  reporting  data 


In  implementing  these  capabilities,  VFDMIS  development  will 


Support  HQDA,  MACOMs,  and  installations  via  interactive  soft 
ware  and  remote  terminal  equipment  using  state-of-the-art 
telecommunications . 


Include  MACOM-unique  requirements 


Integrate  HQDA  and  MACOM  force  development  processing 


Establish  controls  to  balance  forces,  manpower,  and  budget 
data. 


5.  Provide  complete  audit  trails  of  actions  affecting  each  unit— 
active,  reserve.  National  Guard,  and  unmanned — to  the  extent 
practicable. 

6.  Provide  accurate  and  timely  data. 

7.  Perform  on-line  data  value  edits. 

8.  Provide  data  retrieval  to  all  users. 

9.  Reduce  requirements  for  field  reports. 

10.  Provide  MACOMs  and  installations  more  computer  time  by  remov- 
ing VFAS , VTAADS , ITAADS , and  selected  command-unique  systems 
from  field  computers. 

11.  Maintain  all  edit  files  to  ensure  only  current  approved  data 
values  are  processed. 

12.  Incorporate  the  SACS  Information  Gatheiing  and  Analysis  System 
(SIGMA)  logic. 

13.  Incorporate  the  Force  Accounting  Terminal  System  (FACTS)  and 
Rapid  Authorization  Data  Retrieval  (RADAR)  logic  into  one 
cohesive  capability. 

14.  Incorporate  the  Force  Systems  Branch  Remote  Job  Entry  (FSB/ 
RJE)  logic. 

15.  Incorporate  the  Automatic  Validation  (AUTOVAL)  logic  as  a 
means  to  generate  data,  reduce  terminal  operator  input,  and 
perform  data  value  edits. 

16.  Incorporate  the  capability  to  view  and  compare  various  VFDMIS 
files. 

17.  Incorporate  EDATE  and  documentation  rules. 

18.  Incorporate  TOE  for  MTOE  development  and  edit  purposes. 

The  VFDMIS  will  provide  a great  improvement  in  overall  response 
time  and  authorization  document  development  time  for  reaction  to  guidance 
and  documentation  of  manpower  allocation  changes  through  the  on-line  real- 
time capability. 
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The  VFDMIS , when  completely  developed  and  implemented,  will  be  a 
state-of-the-art  system;  however,  there  will  be  requirements  for  SACS-type 
processing.  A continuation  of  SACS-type  processing  will  be  needed  to: 

1.  Freeze  the  force  at  a point  in  time. 

2.  Review  outstanding  resource  command  management  accounts  and 
other  pending  actions. 

3.  Select  TOE  detail  in  those  cases  where  TAADS-type  documenta- 
tion does  not  exist. 

4.  Factor  personnel  requirements  because  of  system  lag  time. 

5.  Assemble  SRC  detail  for  plus  and  minus  organizations,  in 
some  cases. 

6.  Review  for  and  correct  negative  personnel  and  equipment 
quantities. 

7.  Process  BOIP  and  SHN  against  the  personnel  and  equipment 
detail. 

8.  Perform  record  count  and  the  improved  PAAS-  and  BOIMARS-type 
audits. 

9.  Maintain  a SACS-type  data  base  for  recurring  and  ad  hoc 
reports  and  as  a retrieval  data  base. 

10.  Maintain  SACS  history  for  a 7-year  period. 

In  addition  to  the  foregoing,  SACS  documentation  requirements  must 
be  developed  and  maintained. 
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